home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13802 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: solon.com!not-for-mail
  2. From: mshan@ibm.net (Mike Shannon)
  3. Newsgroups: comp.lang.c,comp.lang.c.moderated,hp.unix,comp.sys.hp.apps,comp.sys.hp.hpux
  4. Subject: Re: C coding problem
  5. Date: 10 Apr 1996 07:11:01 -0500
  6. Organization: Digital Solutions
  7. Sender: clc@solutions.solon.com
  8. Approved: clc@solutions.solon.com
  9. Message-ID: <4kg8gl$iht@solutions.solon.com>
  10. References: <4ianbf$h86@solutions.solon.com> <4iemcl$a05@solutions.solon.com> <4io1io$no4@solutions.solon.com> <4j06na$808@solutions.solon.com> <4jttan$3gf@solutions.solon.com>
  11. Reply-To: mshan@ibm.net (Mike Shannon)
  12. NNTP-Posting-Host: solutions.solon.com
  13. X-Newsreader: IBM NewsReader/2 v1.2
  14.  
  15. In <4jttan$3gf@solutions.solon.com>, nsmart@indigo.ie (Niall Smart) writes:
  16. >
  17. >>: I recently wrote a loop that went like this:
  18. >
  19. >>: while (p < end_p)
  20. >>:     ++*p++;
  21. >
  22. >>: Maybe some will find it a counter-example; I think it's good
  23. >>: code that embodies the way C is designed to work.  Arrays are
  24. >>: second rate objects in C.  Use pointers.
  25. >
  26. >That code scores negative for maintainability, why use arcane
  27. >features of the language that can be replaced with more readable code?
  28. >If you read any of the books on writing good code you will find
  29. >hundreds of reasons to avoid code like that. The execution time you
  30. >*might* be saving is offset many times by the time it takes a
  31. >maintainer to figure it out.
  32. >
  33. >Secondly, why not use arrays? In many places they are easier to
  34. >understand - I for one am not going to compromise the readability
  35. >of my programs because of some theoretical bull about them
  36. >being second rate objects. (whatever that is intended to mean)
  37. >a[i] is converted to *(a + i) by the compiler in any case so
  38. >whats the advantage with your approach?
  39. >
  40. >Niall
  41.  
  42. Sure, a[i] is the same as *(a+i). Both involve keeping up with
  43. two variables, and, when i incremented, require a multiplication
  44. of i times sizeof(*a) to add to a to find the address of the next
  45. row.
  46.  
  47. But the example above is doing neither. p++ involves only one
  48. variable, and only addition of sizeof(*p) to find the address of
  49. the next row. Notice especially that there is no multiplication
  50. required. Agreed the per event difference is small, but if a
  51. program does a large number of array sweeps, the small
  52. advantage adds up. Some optimizers may do this for you.
  53.  
  54. I agree with simple syntax, though, and expect that something
  55. like:
  56.  
  57.     while (p < end_p)
  58.     {    
  59.          ++(*p);
  60.          p++;
  61.     }
  62.    
  63. would produce the same assembly output as the above example,
  64. and pose less interpretation risk in the future.
  65.  
  66. Mike Shannon
  67. Houston, Texas
  68.  
  69. <!>  Once we had computers and dumb terminals.
  70. <!>  Now we have computers and stupid terminals.
  71. <!>  Thanks, Microsoft.
  72.